The Interactive Network Design Manual

General responses

Data encryption

Encryption can go a long way to help you on your internal as well as your external network communications.

There may be times when you want to send data from one network to another and you can't guarantee that the data won't be intercepted by packet sniffing. This can be true in a corporation that sends confidential information from one department to another. And, it is certainly the case when sending data over the Internet, as it traverses points of presence located at college campuses and telcos. You cannot control the access to the data once it leaves your site (it is difficult at best to control access at your own site). It is best to assume that if someone wants to tap into this data badly enough, he or she will find a way to do it.

The most effec tive way to deal with this vulnerability is to use encryption to ensure that the data is encoded in such a form as to make it meaningless to anyone but the sender and the intended recipient. The encryption of communications has been going on for many decades, but computers make it possible to encrypt data quickly and in such a manner as to make it much more difficult to decrypt without knowing the code. This is accomplished by using a mathematical algorithm that rearranges the bits making up the message many times over in random patterns that makes it impossible to guess the original form of the message. The algorithm used to encode the data relies on an encoding key. The only way to hack the encrypted data is to run it through computers that try every possible key. The bigger the key, the more secure the encryption that results. The most common encryption scheme is a version of DES based on a 40-, 56- or 128-bit key. A 40-bit key can be cracked in a number of days with enough high-powered Unix workstations. Even 56-bit keys are considered vulnerable by some experts, to an attacker who has enough expertise and computing power For more information about encryption, visit RSA Data Security .

The key problem

In order for an encrypted conversation to take place, both sides have to know the key used to encrypt and decrypt the data. If anyone else gets the key that is used, they will be able to unlock the conversation just as easily as the intended recipient. This is why this type of key is called a "private key," and belies one of the biggest problems with setting up encryption. How do you get the key to the other party without it being intercepted? If you send it over the same network, it is just as vulnerable as the conversation that you are trying to protect. If you tell the other party on a voice line, then you can be just as vulnerable. You can always mail it, and using an overnight service will certainly speed things up, but this is not exactly the high-band width communications that we have grown accustomed to.

Time to get keyed up

One way that this is dealt with is by using a two key approach which was developed by RSA. With this approach, everyone has both a public and a private key. The public key is freely distributed. The private key is held onto, thus greatly minimizing the risks associated with communicating the key to another party. When a message is sent, it is encrypted using the receipient's public key. When the owner of the corresponding private key receives the message, it is deciphered using his own private key. If two parties exchange their public keys, they can have an encrypted two-way conversation. One disadvantage of this method is that the keys are large and require a lot of CPU to process a message. For this reason it is often used to exchange a simpler private key that will be used to decode the rest of the message.

The private key can also be used by the sender in order to provide proof that it was sent by the sender. RSA makes it possible to decrypt a message that hasn't yet been encrypted. After it is decrypted, the only way it can be recovered is by encrypting it with the corresponding public key. Of course the public key is available to everyone, which only means that anyone can verify that it was actually sent by the person with the private key. The message is still encrypted, but by using the public key of the intended recipient.

Nortel's Entrust software has gone a long way towards managing the problem of keys. Entrust was reviewed in our Nov. 1, 1996 feature.

Where to encrypt

There are a number of locations where encryption can take place:

At the application: Examples of this are Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME), which provide encryption for e-mail.

At the client or host network layer: This can be done on the client with products l ike Netlock (link to www.netlock.com), which provide encryption on multiple operating system platforms at the IP level. You can set it up so that a system will only accept encrypted communications with certain hosts. The advantage of this approach is that you provide extra protection for your hosts that will be in place even if there is no firewall or if it is compromised. The other advantage is that it allows you to distribute the burden of processing the encryption among the individual hosts involved. You will find similar approaches from Netmanage , and FTP Software.

At the firewall network layer: Many firewalls come with a feature called virtual private network (VPN) . VPNs allows encryption to take place as data leaves the firewall. It has to be decrypted at a firewall on the other end before it is sent to the receiving host. The advantage to this approach is that there is centralized control of encryption which can be set up based on IP address or port filter. It can cause a processing burden on the firewall, especially if a lot of streams that have to be encrypted or decrypted.

At the link level: Products like those manufactured by Cylink encrypt data after it leaves the firewall or router connected to a WAN link. The hardware in this case is solely dedicated to the encryption process, thus offloading the burden from a firewall or router. The other advantage of this method is that the whole stream is encrypted, without even a clue as to the IP addresses of the devices communicating. This can only be used on a point to point link as the IP header would not be intact which would be necessary for routing.

Updated November 15, 1996